home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1550.txt < prev    next >
Text File  |  1997-04-01  |  12KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         S. Bradner
  8. Request for Comments: 1550                            Harvard University
  9. Category: Informational                                        A. Mankin
  10.                                                                      NRL
  11.                                                            December 1993
  12.  
  13.  
  14.           IP: Next Generation (IPng) White Paper Solicitation
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Table of Contents
  23.  
  24.    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
  25.    2.   Document Review Process  . . . . . . . . . . . . . . . . . . 2
  26.    3.   Document Format Requirement  . . . . . . . . . . . . . . . . 2
  27.    4.   Outline for IPng Requirements and Concerns White Papers  . . 3
  28.    5.   Engineering considerations . . . . . . . . . . . . . . . . . 3
  29.    6.   Security Considerations  . . . . . . . . . . . . . . . . . . 5
  30.    7.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5
  31.    Appendix A - Formatting Rules (from RFC 1543) . . . . . . . . . . 6
  32.  
  33. 1. Introduction
  34.  
  35.    The IP: next generation (IPng) area in the IETF is soliciting white
  36.    papers on topics related to the IPng requirements and selection
  37.    criteria.
  38.  
  39.    All interested parties are invited to submit white papers detailing
  40.    any specific requirements that they feel an IPng must fulfill or any
  41.    factors that they feel might sway the IPng selection.  An example of
  42.    the former might be a submission by a representative of a utility
  43.    company detailing the scaling and addressing features which would be
  44.    required to service future inclusion of utility meters on the
  45.    network.  An example of the other case might be a paper outlining the
  46.    potential effect on IPng of some sections of the future network
  47.    connectivity being provided via wireless networks.
  48.  
  49.    At this time, we are not accepting white papers that evaluate
  50.    specific IPng proposals.  This type of document will be accepted
  51.    after the various proposal documents are deemed to be clear and
  52.    complete.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Bradner & Mankin                                                [Page 1]
  59.  
  60. RFC 1550             IPng White Paper Solicitation         December 1993
  61.  
  62.  
  63.    All white papers will be reviewed in a process described below.  As a
  64.    result of these reviews, each white paper will receive the focused
  65.    attention of the IPng directorate and the community.  The white
  66.    papers will be used as resource materials by the IPng Area working
  67.    groups, the directorate, the external review board and the area
  68.    directors, during the selection process.
  69.  
  70.    The deadline for the submission of these white papers is February 1,
  71.    1994, though early submission is encouraged.
  72.  
  73.    Submit white papers, general or topic questions, and so on, to
  74.    ipng-wp@harvard.edu.
  75.  
  76. 2. Document Review Process
  77.  
  78.    All submitted documents will first be reviewed for clarity by members
  79.    of the IPng directorate and the external review board.  This review
  80.    may produce suggestions to the author on areas of the document where
  81.    there may be some confusion as to the meaning.  Authors are urged to
  82.    consider any such suggestions as constructive and to reexamine their
  83.    text in light of the suggestions.
  84.  
  85.    A separate technical review will then be done of the white paper.
  86.    This review will be conducted within the context of the document.
  87.    That is, the review still will not make value judgments on the white
  88.    papers, but will assess technical feasibility.  This review may also
  89.    produce suggestions to the author.
  90.  
  91.    The document will be submitted as an Internet-Draft after these
  92.    reviews have been completed and after whatever (if any) revisions
  93.    that the author decides to make.   After a suitable period of time
  94.    these documents will be submitted as informational RFCs unless
  95.    withdrawn by the author.  These documents will comprise a part of the
  96.    historical record of the IPng process.
  97.  
  98. 3. Document Format Requirements
  99.  
  100.    All white papers must follow the format requirements listed in RFC
  101.    1543 and must not exceed 10 pages in length. (The relevant portion of
  102.    RFC 1543 is included in this document as Appendix A.)  They should
  103.    not include the "status of memo" section; this will be added when the
  104.    documents are posted as Internet Drafts.  The reference version of
  105.    the document must be in ASCII as is current practice with all RFCs.
  106.    A PostScript version of the document may be submitted in addition to
  107.    the ASCII version. (See RFC 1543 for the formatting procedures to use
  108.    with PostScript documents.)
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Bradner & Mankin                                                [Page 2]
  115.  
  116. RFC 1550             IPng White Paper Solicitation         December 1993
  117.  
  118.  
  119. 4. Outline for IPng Requirements and Concerns White Papers
  120.  
  121.    This section details the white paper outline to be followed by
  122.    someone who would like to express an opinion about the various
  123.    factors involved in the IPng definition and selection process.  Since
  124.    these documents will be used as resource material by the various IPng
  125.    working groups, the directorate, the external review board and the
  126.    area directors, they should be well-focused and give specific
  127.    references to data supporting their points.
  128.  
  129.    Each white paper should begin with an executive summary of the
  130.    important points of the document.  This executive summary should not
  131.    exceed 1/2 page in length.
  132.  
  133.    The white paper should then address the issue or issues that the
  134.    author feels should be understood during the IPng process.  The total
  135.    document should not exceed 10 pages in length.  An author may submit
  136.    more than one white paper if he or she feels that the level of
  137.    detailed discussion on each topic warrants it.
  138.  
  139. 5. Engineering considerations
  140.  
  141.    In past discussions the following issues have been raised as relevant
  142.    to the IPng selection process.  This list is in no particular order.
  143.    Any or all of these issues may be addressed as well as any other
  144.    topic that the author feels is germane, but do not exceed the 10 page
  145.    limit, please.
  146.  
  147.    5.1  Scaling - What is a reasonable estimate for the scale of the
  148.       future data networking environment?  The current common wisdom is
  149.       that IPng should be able to deal with 10 to the 12th nodes.
  150.  
  151.    5.2  Timescale - What are reasonable time estimates for the IPng
  152.       selection, development and deployment process or what should the
  153.       timeframe requirements be?  This topic is being evaluated by the
  154.       ALE working group and a copy of all white papers that express
  155.       opinions about these topics will be forwarded to that group.
  156.  
  157.    5.3  Transition and deployment - Transition from the current version
  158.       to IPng will be a complex and difficult process.  What are the
  159.       issues that should be considered The TACIT working group will be
  160.       discussing these issues and a copy of all white papers that
  161.       express opinions about these topics will be forwarded to that
  162.       group.
  163.  
  164.    5.4  Security - What level and type of security will be required in
  165.       the future network environment?  What features should be in an
  166.       IPng to facilitate security?
  167.  
  168.  
  169.  
  170. Bradner & Mankin                                                [Page 3]
  171.  
  172. RFC 1550             IPng White Paper Solicitation         December 1993
  173.  
  174.  
  175.    5.5  Configuration, administration and operation - As networks get
  176.       larger and more complex, the day to day operational aspects become
  177.       ever more important.  What should an IPng include or avoid in
  178.       order to minimize the effect on the network operators?
  179.  
  180.    5.6  Mobile hosts - How important is the proliferation of mobile
  181.       hosts to the IPng selection process?  To what extent should
  182.       features be included in an IPng to assist in dealing with mobile
  183.       hosts?
  184.  
  185.    5.7  Flows and resource reservation - As the data networks begin to
  186.       get used for an increasing number of time-critical processes, what
  187.       are the requirements or concerns that affect how IPng should
  188.       facilitate the use of resource reservations or flows?
  189.  
  190.    5.8  Policy based routing - How important is policy based routing?
  191.       If it is important, what types of policies will be used?  What
  192.       requirements do routing policies and potential future global
  193.       architectures of the Internet bring to IPng?  How do policy
  194.       requirements interact with scaling?
  195.  
  196.    5.9  Topological flexibility - What topology is anticipated for the
  197.       Internet?  Will the current general topology model continue?  Is
  198.       it acceptable (or even necessary) to place significant topological
  199.       restrictions on interconnectivity of networks?
  200.  
  201.    5.10 Applicability - What environment / marketplace do you see for
  202.       the application of IPng?  How much wider is it than the existing
  203.       IP market?
  204.  
  205.    5.11 Datagram service - Existing IP service is "best effort" and
  206.       based on hop-by-hop routed datagrams.  What requirements for this
  207.       paradigm influence the IPng selection?
  208.  
  209.    5.12 Accounting - How important a consideration should the ability to
  210.       do accounting be in the selection of an IPng?  What, if any,
  211.       features should be included in an IPng to support accounting
  212.       functions?
  213.  
  214.    5.13 Support of communication media - IPv4 can be supported over most
  215.       known types of communications media.  How important is this same
  216.       flexibility to an IPng?
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bradner & Mankin                                                [Page 4]
  227.  
  228. RFC 1550             IPng White Paper Solicitation         December 1993
  229.  
  230.  
  231.    5.14 Robustness and fault tolerance - To the extent that the Internet
  232.       built from IPv4 has been highly fault tolerant, what are ways that
  233.       IPng may avoid inadvertent decrease in the robustness (since some
  234.       things may work despite flaws that we do not understand well).
  235.       Comment on any other ways in which this requirement may affect the
  236.       IPng.
  237.  
  238.    5.15 Technology pull - Are there technologies that will pull the
  239.       Internet in a way that should influence IPng?  Can specific
  240.       strategies be developed to encompass these?
  241.  
  242.    5.16 Action items - suggested charges to the directorate, working
  243.       groups or others to support the concerns or gather more
  244.       information needed for a decision.
  245.  
  246. 6.  Security Considerations
  247.  
  248.    This RFC raises no security issues, but does invite comment on the
  249.    security requirements of IPng.
  250.  
  251. 7.  Authors' Addresses
  252.  
  253.    Scott Bradner
  254.    Harvard University
  255.    10 Ware St.
  256.    Cambridge, MA 02138
  257.  
  258.    Phone: (617) 495-3864
  259.  
  260.    EMail: sob@harvard.edu
  261.  
  262.  
  263.    Allison Mankin
  264.    Naval Research Laboratory
  265.    c/o Code 5591
  266.    Washington D.C. 20375-5000
  267.  
  268.    Phone: 202-404-7030
  269.  
  270.    EMail: mankin@cmf.nrl.navy.mil
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Bradner & Mankin                                                [Page 5]
  283.  
  284. RFC 1550             IPng White Paper Solicitation         December 1993
  285.  
  286.  
  287. Appendix  A - Formatting Rules (from RFC 1543)
  288.  
  289.    Note: there are a set of NROFF formatting macros for the following
  290.    format.  Please contact ipng-wp@harvard.edu if you would like to get
  291.    a copy.
  292.  
  293.    3a.  ASCII Format Rules
  294.  
  295.       The character codes are ASCII.
  296.  
  297.       Each page must be limited to 58 lines followed by a form feed on a
  298.       line by itself.
  299.  
  300.       Each line must be limited to 72 characters followed by carriage
  301.       return and line feed.
  302.  
  303.       No overstriking (or underlining) is allowed.
  304.  
  305.       These "height" and "width" constraints include any headers,
  306.       footers, page numbers, or left side indenting.
  307.  
  308.       Do not fill the text with extra spaces to provide a straight right
  309.       margin.
  310.  
  311.       Do not do hyphenation of words at the right margin.
  312.  
  313.       Do not use footnotes.  If such notes are necessary, put them at
  314.       the end of a section, or at the end of the document.
  315.  
  316.       Use single spaced text within a paragraph, and one blank line
  317.       between paragraphs.
  318.  
  319.       Note that the number of pages in a document and the page numbers
  320.       on which various sections fall will likely change with
  321.       reformatting.  Thus cross references in the text by section number
  322.       usually are easier to keep consistent than cross references by
  323.       page number.
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Bradner & Mankin                                                [Page 6]
  339.